Editorial: Refactor time zone identifier spec text#2573
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2573 +/- ##
==========================================
- Coverage 96.15% 96.13% -0.02%
==========================================
Files 20 20
Lines 11480 11580 +100
Branches 2170 2205 +35
==========================================
+ Hits 11039 11133 +94
- Misses 377 383 +6
Partials 64 64
|
efa9806 to
a12431e
Compare
01031a1 to
83d02b5
Compare
ptomato
left a comment
There was a problem hiding this comment.
In general, looks pretty good to me. I have some minor comments about phrasing. Looking forward to seeing what happens with this after the direction of the ECMA-262 PR becomes clearer.
justingrant
left a comment
There was a problem hiding this comment.
Thanks for the review! Other than the recommended/required comments, I agree with all your feedback and will make those changes. Let's discuss the recommendation thing further.
Looking forward to seeing what happens with this after the direction of the ECMA-262 PR becomes clearer.
Based on my last convo with the 262 editors, the 262 PR is likely to be a subset of what's here. Planning to update the 262 PR tomorrow with a new draft of that subset.
But I don't anticipate major changes to the content in this PR... main questions seem to be about where and when the text will go (262 now vs. 262 and 402 later via Temporal) not necessarily about the text itself.
This commit simplifies and clarifies spec text related to time zone identifiers. Goals include making it easier to integrate Temporal into ECMA-262 soon, and simplifying both Temporal and ECMA-402 spec text by centralizing common logic in ECMA-262. If this commit is merged into ECMA-262, editorial PRs will follow for Temporal (draft: tc39/proposal-temporal#2573) and ECMA-402 (draft TBD) to leverage the updated spec text and AOs to simplify those specs. Changes: * Adds editorial spec text explaining how time zone identifiers work in ECMAScript, and pointing readers to 402 for implementations that use the IANA TimeZoneDatabase. * Adds definitions related to time zone identifiers. * Renames `DefaultTimeZone` to `SystemTimeZoneIdentifier` in order to more clearly match its intent. * Removes the need to override `SystemTimeZoneIdentifier` in ECMA-402. * Renames variables named _timeZone_ to _timeZoneIdentifier_ to avoid future ambiguity with `Temporal.TimeZone`. * Adds text that more clearly explains existing spec text allowing non-402 implementations to support non-UTC time zones. * Adds new abstract operation `AvailableTimeZoneIdentifiers`which, along with the existing (renamed to) `SystemTimeZoneIdentifier`, enables all ECMA-402 and Temporal operations related to time zone identifiers to be implemented on top of these AOs.
4327354 to
a131620
Compare
This commit simplifies and clarifies spec text related to time zone identifiers. Goals include making it easier to integrate Temporal into ECMA-262 soon, and simplifying both Temporal and ECMA-402 spec text by centralizing common logic in ECMA-262. If this commit is merged into ECMA-262, editorial PRs will follow for Temporal (draft: tc39/proposal-temporal#2573) and ECMA-402 (draft TBD) to leverage the updated spec text and AOs to simplify those specs. Changes: * Adds editorial spec text explaining how time zone identifiers work in ECMAScript, and pointing readers to 402 for implementations that use the IANA TimeZoneDatabase. * Adds definitions related to time zone identifiers. * Renames `DefaultTimeZone` to `SystemTimeZoneIdentifier` in order to more clearly match its intent. * Removes the need to override `SystemTimeZoneIdentifier` in ECMA-402. * Renames variables named _timeZone_ to _timeZoneIdentifier_ to avoid future ambiguity with `Temporal.TimeZone`. * Adds text that more clearly explains existing spec text allowing non-402 implementations to support non-UTC time zones. * Adds new abstract operation `AvailableTimeZoneIdentifiers`which, along with the existing (renamed to) `SystemTimeZoneIdentifier`, enables all ECMA-402 and Temporal operations related to time zone identifiers to be implemented on top of these AOs.
c94507c to
daca88c
Compare
This commit simplifies and clarifies spec text related to time zone identifiers. Goals include making it easier to integrate Temporal into ECMA-262 soon, and simplifying both Temporal and ECMA-402 spec text by centralizing common logic in ECMA-262. If this commit is merged into ECMA-262, editorial PRs will follow for Temporal (draft: tc39/proposal-temporal#2573) and ECMA-402 (draft TBD) to leverage the updated spec text and AOs to simplify those specs. Changes: * Adds editorial spec text explaining how time zone identifiers work in ECMAScript, and pointing readers to 402 for implementations that use the IANA TimeZoneDatabase. * Adds definitions related to time zone identifiers. * Renames `DefaultTimeZone` to `SystemTimeZoneIdentifier` in order to more clearly match its intent. * Removes the need to override `SystemTimeZoneIdentifier` in ECMA-402. * Renames variables named _timeZone_ to _timeZoneIdentifier_ to avoid future ambiguity with `Temporal.TimeZone`. * Adds text that more clearly explains existing spec text allowing non-402 implementations to support non-UTC time zones. * Adds new abstract operation `AvailableTimeZoneIdentifiers`which, along with the existing (renamed to) `SystemTimeZoneIdentifier`, enables all ECMA-402 and Temporal operations related to time zone identifiers to be implemented on top of these AOs.
This commit simplifies and clarifies spec text related to time zone identifiers. Goals include making it easier to integrate Temporal into ECMA-262 soon, and simplifying both Temporal and ECMA-402 spec text by centralizing common logic in ECMA-262. If this commit is merged into ECMA-262, editorial PRs will follow for Temporal (draft: tc39/proposal-temporal#2573) and ECMA-402 (draft TBD) to leverage the updated spec text and AOs to simplify those specs. Changes: * Adds editorial spec text explaining how time zone identifiers work in ECMAScript, and pointing readers to 402 for implementations that use the IANA TimeZoneDatabase. * Adds definitions related to time zone identifiers. * Renames `DefaultTimeZone` to `SystemTimeZoneIdentifier` in order to more clearly match its intent. * Removes the need to override `SystemTimeZoneIdentifier` in ECMA-402. * Renames variables named _timeZone_ to _timeZoneIdentifier_ to avoid future ambiguity with `Temporal.TimeZone`. * Adds text that more clearly explains existing spec text allowing non-402 implementations to support non-UTC time zones. * Adds new abstract operation `AvailableNamedTimeZoneIdentifiers` which, along with the existing (renamed) `SystemTimeZoneIdentifier`, enables all ECMA-402 and Temporal operations related to time zone identifiers to be implemented on top of these AOs.
de702fb to
2f3d98c
Compare
68a71e3 to
aac6066
Compare
| </emu-clause> | ||
| </ins> | ||
|
|
||
| <del class="block"> |
There was a problem hiding this comment.
Note that this entire section (the following ~70 lines) is deleted from ECMA-402 and replaced with the new section above (and with new AOs in 262 like AvailableTimeZoneIdentifiers and GetAvailableTimeZoneIdentifier).
So don't bother reviewing anything about the text in here except validating that it's OK to remove these AOs.
aac6066 to
f02f5be
Compare
| <p> | ||
| Time zones in ECMAScript are represented by <dfn variants="time zone identifier">time zone identifiers</dfn>, which are Strings composed entirely of code units in the inclusive interval from 0x0000 to 0x007F. | ||
| Time zones supported by an ECMAScript implementation may be <dfn variants="available named time zone">available named time zones</dfn>, represented by the [[Identifier]] field of the Time Zone Identifier Records returned by AvailableNamedTimeZoneIdentifiers, or <dfn variants="offset time zone">offset time zones</dfn>, represented by Strings for which IsTimeZoneOffsetString returns *true*. | ||
| <ins>Time zone identifiers are compared using ASCII-case-insensitive comparisons.</ins> |
There was a problem hiding this comment.
The 262 editors wanted us to move this line into Temporal because it wasn't needed to support current 262 text.
| </emu-alg> | ||
| </emu-clause> | ||
| </emu-clause> | ||
| <emu-clause id="sec-date-objects"> |
There was a problem hiding this comment.
This section has a lot of green text, but most of it duplicates what's newly added to ECMA-262, so you don't have to review or even read it all if you don't want to.
To make it easier to spot the changes, I added notes below for the three small places where the text is changed from current 262.
aad99c8 to
d55945b
Compare
|
Thanks @gibson042 for the thorough review! I made most of the changes you recommended, suggested that some of them were out of scope, and had a few questions and follow-ups. @ptomato I'll look for your review next week. Thanks! |
d55945b to
c6a8a54
Compare
| <p>This definition supersedes the definition provided in <emu-xref href="#sec-canonicalizetimezonename"></emu-xref>.</p> | ||
| </ins> | ||
| <emu-clause id="sup-defaulttimezone" oldids="sec-defaulttimezone" type="implementation-defined abstract operation"> | ||
| <h1>DefaultTimeZone ( ): a String</h1> |
There was a problem hiding this comment.
The only reason this shows up in green is because it's being deleted from 402. Can ignore.
c6a8a54 to
948481e
Compare
ptomato
left a comment
There was a problem hiding this comment.
I wonder if we can just not have the CLDR timezone database? It seems acceptable to be less exhaustive there.
Other than that, only a few Ecmarkup syntax nitpicks. I didn't review the prose as carefully as last time, I figure it's already been scrutinized plenty by the ECMA-262 editors.
46c3b21 to
63492fc
Compare
This commit builds on the new ECMA-262 text for time zone identifiers that was introduced in tc39/ecma262#3035. This commit adds Temporal-specific AOs and makes a handful of edits to ECMA-262 AOs for changes that didn't apply to %Date% but that will be required after Temporal is merged into ECMA-262. This commit also revises the ASCII-case-insensitive section to address feedback from ECMA-262 editors before this text was removed from tc39/ecma262#3035: * Remove the "sequence of code points" info because only Strings seemed to use these definitions. * Minor wordsmithing, e.g. "string value" => "String"
63492fc to
4224ae6
Compare
|
PR is rebased on main and all review comments are resolved, except for @ptomato's concern about testing the entire list of CLDR IDs. But I think we should keep those in for now, and then consider removing them if proposal-canonical-tz moves forward far enough for Test262 to be able to validate case normalization. So unless there are objections, I'd like to merge this PR as-is (so I can unblock other stuff stacked on this PR) and revisit later if needed. Holler if this is a problem, otherwise I'll plan to merge later today. Thanks! |
4224ae6 to
dc088aa
Compare
dc088aa to
192acba
Compare
This PR refactors how the Temporal spec deals with time zone identifiers. Summary is below.
This PR is a companion to the just-merged tc39/ecma262#3035 which performed a similar refactor in ECMA-262.
Changes to 262 section of the Temporal spec
DefaultTimeZonetoSystemTimeZoneIdentifier(It was renamed in 262 to more clearly match what it does. Also because Temporal doesn't have a "default" time zone likeDatehas.)AvailableTimeZoneNames,CanonicalizeTimeZoneNameandIsAvailableTimeZoneName, and replaces them with calls to a new AOGetAvailableTimeZoneIdentifier.Changes to 402 section of the Temporal spec
AvailableTimeZoneIdentifiers.AvailableTimeZoneIdentifiers,CanonicalizeTimeZoneNameandIsAvailableTimeZoneName, and replaces them with calls toGetAvailableTimeZoneIdentifier. A later editorial PR to 402 will make the same changes there, and also replace its newAvailableCanonicalTimeZoneNamesAO with anAvailableTimeZoneIdentifiers-based version.When reviewing this PR, remember that many of the changes are removing spec text, which in the 402 section of the spec causes a confusing diff because the text isn't actually removed from the file but rather is just put into a larger
<del>block. I added review notes in the spec text to make this clearer.This PR also includes polyfill changes to more closely match the new spec text.